\documentclass[a4paper,10pt,twocolumn]{article}
\usepackage[italian]{babel}
\usepackage[utf8x]{inputenc}
\usepackage{balance}
\usepackage[dvipdfm]{graphicx}
\usepackage{wrapfig}
\usepackage{verbatim}
\usepackage{amsfonts}
\usepackage{color}
\usepackage{epsfig}
\usepackage{indentfirst}
\usepackage{makeidx}
\usepackage{listings}
\usepackage{fancyhdr}
\usepackage{tocloft}
\usepackage{titletoc} 
\usepackage{amsmath} 
\usepackage{amssymb}
\usepackage{ccaption}
\usepackage{longtable}
\usepackage{multirow}
\usepackage{multicol} 
\usepackage{array}

\setlength{\columnsep}{0.25in}

\hyphenation{mi-su-ra-to}
\hyphenation{pro-ba-bil-men-te}
\hyphenation{ge-ne-ra-zio-ne}
\hyphenation{i-nol-tre}
\hyphenation{ri-u-scen-do}
\hyphenation{ca-rat-te-riz-za-no}
\hyphenation{e-sten-de-re}
\hyphenation{i-nol-tro}
\hyphenation{si-mi-le}
\hyphenation{e-le-va-to}
\hyphenation{e-sten-sio-ne}
\hyphenation{listener}
\hyphenation{package}
\hyphenation{timestamp}


\begin{document}
%\maketitle
\begin{titlepage}
  	\vspace*{5cm}
  \begin{center}
    \Huge \textbf{P2P - Monitor e Logger Globale}\\
	\Large \textit{Documento di presentazione per la tesina di Sistemi Distribuiti} \\ \large
    \vspace{3cm}
    Dario Mazza,\\
	Paolo Pino,\\
	Pierluigi Sottile
  \end{center}

\end{titlepage}
\onecolumn
\tableofcontents
\newpage
\twocolumn
\balance
\section{Consegna}
L'obiettivo della tesina è di realizzare un servizio di Logging e un servizio di Monitor Globale che riceverà i dati provenienti dai peer realizzati nel primo step. I messaggi all'interno dei componenti globali devono essere ordinati prima di essere scritti in dei file XML. I messaggi inviati ai componenti globali devono essere generati da un sistema di logging e monitoring locale ai peer.

Deve essere replicato il contenuto di una delle tre code del peer utilizzando un sistema transazionale.

Tutte le comunicazioni devono essere implementate utilizzando i Web Service di Java Enterprise Edition e l'Application Server \textit{Glassfish}.
\section{Logging Locale}
Il sistema di logging locale si basa sull'utility \textbf{log4j} dell'\textit{Apache Software Foundation}. Questa utility fornisce metodi per la creazione di logger e l'associazione di appender specifici al sistema di logging. 

Il logging locale è diviso in due parti: la prima è composta da un serie di logger mappati sulle classi che
li utilizzano e serve per lo sviluppo ed il debugging dell'applicazione. Questa prima parte produce due file contenenti gli stessi dati: \texttt{middleware\_p2p.out}, scritto in formato human-readable, e \texttt{middleware\_p2p.log}, formattato in XML in base al DTD di log4j. La seconda parte del logging è composta da un filtro sui logger della prima parte e serve per catturare i dati da inviare al componente globale. Questa seconda parte produce un file, \texttt{middleware\_local.log}, formattato in XML.

I log che vengono inviati al logger globale sono solo quelli di livello \texttt{INFO} e devono essere del tipo \texttt{MiddlewareLogEvent}. Estendendo il layout XML (classe \texttt{XMLLayout} contenuta nelle API log4j) è stata personalizzata la formattazione del file ed è stata inserita una chiamata al Web Service \texttt{GlobalLogger} per eseguire il \texttt{push} dell'evento di log.

La classe MiddlewareLogEvent contiene l'identificativo univoco del componente (ossia del peer), il timestamp locale dell'evento, una stringa contenente la descrizione dell'evento e il Vector Clock necessario all'ordinamento degli eventi all'interno del componente globale. L'identificativo del componente viene generato applicando la funzione di hash MD5 alla stringa \textit{"Component:peer\_ip:peer\_port"}.

\paragraph{Interfaccia XMLSerializable e JAXB}
Tutte le classi, come MiddlewareLogEvent, che devono essere serializzate in XML implementano l'interfaccia
\texttt{XmlSerializable} (che estende java.io.Serializable) che prevede il metodo \texttt{public String toXmlString()}. Quest'ultimo metodo viene utilizzato dai layout per ottenere la rappresentazione XML dell'oggetto.

La rappresentazione XML viene ottenuta tramite l'uso di \textbf{JAXB} (Java Architecture for XML Binding).
Per definire la struttura dell'oggetto complesso XML vengono utilizzate le annotazioni \texttt{@XmlRootElement}, \texttt{@XmlType}, \texttt{@XmlElement}. Per eseguire il marshalling si utilizza l'oggetto Marshaller di JAXB. Utilizzare JAXB per la serializzazione XML ha diversi vantaggi: in primo luogo semplifica lo sviluppo dei metodi di serializzazione ed inoltre si tratta di un elemento di Java EE ed è utilizzato da \textit{JAX-WS} (Java API for XML Web Service) per generare il WSDL dei Web Service.

\section{Monitoring Locale}
Il monitoring locale si appoggia al sistema log4j per la scrittura dello stato e del contenuto delle code su file XML. Il sistema di monitoring è composto da quattro logger:
\begin{itemize}
\item \texttt{middleware.p2p.monitor.wfqueue} sul quale viene scritto il contenuto della coda di Workflow
\item \texttt{middleware.p2p.monitor.tdqueue} sul quale viene scritto il contenuto della coda di Task Descriptor
\item \texttt{middleware.p2p.monitor.wfqueue\_status} sul quale viene scritto lo stato della coda di Workflow
\item \texttt{middleware.p2p.monitor.tdqueue\_status} sul quale viene scritto lo stato della coda di Task Descriptor
\end{itemize}
Agli appender su file delle API di log4j (contenuti nella classe \texttt{org.apache.log4j.FileAppender}) viene applicato un filtro \texttt{MonitorFilter} che permette di applicare il layout \texttt{MiddlewareMonitorLayout} ad un logger con un determinato nome. Il layout si occupa di formattare i file XML in maniera appropriata e di inviare l'evento al Web Service \texttt{GlobalMonitor} per effettuare il \texttt{push}. I file generati dal monitoring locale sono:
\begin{itemize}
\item \texttt{middleware\_wfqueue\_content.log}, 
\item \texttt{middleware\_wfqueue\_status.log},  
\item \texttt{middleware\_tqueue\_content.log},  
\item \texttt{middleware\_tqueue\_status.log} 
\end{itemize}
che contengono, rispettivamente,rispettivamente, il contenuto e lo stato della coda di Workflow ed il contenuto e lo stato della coda di TaskDescriptor.

Gli oggetti che sono scritti nei logger del sistema di monitoring sono del tipo \texttt{MiddlewareMonitorEvent} e contengono il tipo della coda da cui è generato l'evento di monitor, l'identificativo del componente, il Vector Clock necessario all'ordinamento degli eventi nel monitor globale, il timestamp locale dell'evento, il numero totale di elementi inseriti nella coda, la dimensione corrente della coda e la serializzazione XML del contenuto della coda. Quest'ultimo campo non viene serializzato da JAXB grazie all'annotazione \texttt{@XmlTransient}.

\paragraph{Estrazione dello stato e concorrenza}
Nel primo step del Progetto la concorrenza sulle code nei peer era stata gestita tramite la classe \texttt{java.util.concurrent.LinkedBlockingDequeue} che garantisce l'atomicità e la concorrenza nelle operazioni di enqueue e dequeue. La necessità di estrarre lo stato della coda all'interno della sezione critica che modifica lo stato ha imposto il cambiamento del sistema di gestione della concorrenza.

La concorrenza sulle code è gestita applicando il problema di Produttori e Consumatori e utilizzando le classi \texttt{java.util.concurrent.locks.Lock} (utilizzati allo stesso modo dei \texttt{pthread\_mutex}) e \texttt{java.util.concurrent.locks.Condition} (utilizzati come i \texttt{pthread\_cond}).

I metodi enqueue e dequeue sono stati modificati per ricevere un parametro supplementare di tipo MiddlewareMonitorEvent che sarà valorizzato in sezione critica con i dati sullo stato.
\section{Ordinamento dei Messaggi}
Prima di analizzare i componenti globali (Monitor, Logger e Replica Manager) verrà illustrato il sistema di ordinamento dei messaggi basati sui Vector Clock e su un meccanismo di Gap Detection. Il sistema verrà illustrato in forma generica in quanto è stato utilizzato in modo sostanzialmente identico in tutti i componenti globali.

Gli attori del sistema sono due \textbf{EJB} (Enterprise Java Beans):
\begin{itemize}
\item \texttt{Service} : EJB Stateless su cui viene mappato il Web Service
\item \texttt{QueueManager}: EJB Statefull Singleton che viene utilizzato per gestire l'ordinamento
\end{itemize}

Il Web Service espone come WebMethod un metodo \texttt{push} per inserire nel sistema di ordinamento un nuovo elemento e un metodo \text{resetClock} che server per resettare il clock relativo ad un determinato componente. Questi metodi sono soltanto un punto di accesso per i metodi omonimi esposti dall'interfaccia locale del \texttt{QueueManager}.

Il \texttt{QueueManager} mantiene un Vector Clock utilizzato per ordinare i messaggi e una coda in cui vengono inseriti gli elementi che non sono consegnabili immediatamente. 

Il metodo \texttt{push} controlla se il messaggio è \texttt{delivarable} (consegnabile) e in tal caso chiama immediatamente il metodo privato \texttt{deliver} e controlla nella coda di messaggi se ci sono messaggio sbloccati dalla consegna del messaggio corrente e li consegna. Se il messaggio non è consegnabile immediatamente (\textit{immediate delivery} impossibile) viene inserito nella coda di attesa.

Un messaggio viene considerato delivarable se soddisfa una delle seguenti condizioni:
\begin{enumerate}
\item $VC_Q<VC_m \wedge NOT\,Gap \wedge Prox$
\item $VC_Q=VC_m \wedge Prox$
\end{enumerate}
dove $VC_Q$ e $VC_m$ sono i vector clock rispettivamente del \texttt{QueueManager} e del messaggio, $Gap$ è vero se tra $VC_Q$ e $VC_m$ vi sono dei gap e $Prox$ è vero se $VC_Q$ e $VC_m$ sono marcati come prossimi. 

Il metodo \texttt{deliver} esegue le operazioni specifiche del componente legate alla consegna ma prima aggiorna il vector clock del \texttt{QueueManager} in modo che $VC_Q[k]=max(VC_Q[k],VC_m[k]), \, \forall k \in NS$, dove k è l'identificavo di un peer e NS è l'insieme dei peer conosciuti dal componente.

\paragraph{Confronti tra Vector Clock}
L'ordinamento dei messaggi su Vector Clock si basa su tre metodi di confronto tra i Vector Clock:
\begin{itemize}
\item \texttt{compareTo}: implementa il confronto diretto tra due Vector Clock
\item \texttt{detectGap}: controlla se vi sono gap tra i due Vector Clock
\item \texttt{detectProximity}: controlla se due Vector Clock sono prossimi
\end{itemize}
Il confronto diretto tra i Vector Clock si basa sulla seguente definizione:
\[ 
	VC_1<VC_2 \Leftrightarrow 
\]
\[ 
 VC_1[k]\leq VC_2[k]],\,\forall k \wedge\,\exists k':VC_1[k']<VC_2[k']
\]

Il gap detection conta le distanze tra i componenti del Vector Clock e ritorna Vero se le distanze positive sono presenti in più di una componente.

Due Vector Clock sono considerati prossimi se vi è una distanza positiva solo su una componente e questa distanza è pari ad uno.

\section{Logger e Monitor Globale}
Il \textbf{Logger Globale} sfrutta il meccanismo di ordinamento dei messaggi utilizzando il bean \texttt{GlobalLogger} per il Web Service e il bean \texttt{EventQueueManager} per gestire la coda. Il metodo \texttt{deliver} stampa gli eventi consegnati su un file \texttt{middleware\_global\_log.log} formattato in XML e contenuto nella seguente directory \texttt{\$GLASSFISH\_HOME/domains/\$DOMAIN\_NAME/logs}.

Il \textbf{Monitor Globale} sfrutta il meccanismo di ordinamento dei messaggi utilizzando il bean \texttt{GlobalMonitor} per il Web Service e il bean \texttt{MonitorQueueManager} per gestire la coda. Per il monitor il paradigma per l'ordinamento viene leggermente modificato inserendo, all'interno del \texttt{MonitorQueueManager}, delle code separate per ogni tipo di coda del peer. Il metodo \texttt{deliver} stampa gli eventi consegnati su un file, differente per ogni coda, \texttt{middleware\_\$QUEUE\_TYPE\_status.log} formattato in XML e contenuto nella seguente directory \texttt{\$GLASSFISH\_HOME/domains/\$DOMAIN\_NAME/logs}.

\section{Transazioni}
Nel sistema delle transazioni si identificano tre attori: il \textbf{Client}, \textbf{Transaction Coordinator} e \textbf{Transaction Partecipant}. Il flusso di esecuzione della transazione inizia con il client che inizia la transazione e riceve un identificativo univoco della transazione dal Coordinator; il client esegue tutte le operazioni sui partecipant allegando alle richieste l'identificativo della transazione (i partecipant eseguono il join alla transazione contattando il coordinator). Completate tutte le operazioni, il client richiede la chiusura della transazione ed il coordinator inizia l'algoritmo \textbf{2PC} (Two Phase Commit) e dopo le due fasi ritorna il risultato al client: tale risultato può essere Commit o Abort. 

Nell'implementazione presentata il Web Service che interpreta il ruolo del Transaction Coordinator è mappato sul bean \texttt{TransactionCoordinator} che al suo interno contiene i riferimenti alle interfacce locali degli EJB \texttt{TransactionRepository} (Singleton Stateful) e \texttt{TransactionLogger} (Stateless).  Ogni peer ha il suo Transaction Coordinator locale che chiama quando deve utilizzare il sistema di transazioni.

Il \texttt{TransactionLogger} permette di scrivere su un log lo stato di avanzamento di una transazione; il log viene scritto su file con il nome della transazione all'interno della directory \texttt{logs/transaction/\$RUOLO} (dove \texttt{\$RUOLO} indica se si tratta di un coordinator o di un partecipant) contenuta nella root del domain Glassfish. Il file di log viene utilizzato nel caso di crash del coordinator per riprendere le operazioni che stava eseguendo.

\paragraph{TransactionRepository}
L'Enterprise Java Bean \texttt{TransactionRepository} è un Singleton che contiene una mappa che associa ad ogni \textit{Transaction Id} un oggetto \texttt{Transaction}. Inoltre il \texttt{TransactionRepository} legge i timeout e l'identificativo del coordinatore dal file di configurazione e permette di generare un nuovo \textbf{Transaction Id} assemblato come \texttt{\$COORDID\_\$PROGNUM} (dove \texttt{\$PROGNUM} è un numero progressivo).

Il \texttt{TransactionRepository} è segnato con l'annotazione \texttt{@Startup} quindi viene caricato all'avvio del Application Server Glassfish e nel costruttore viene letto il log file di tutte le transazioni e se si trovano in uno stato di \textit{Prepared} o di \textit{Global Abort} manda il segnale di Abort a tutti i partecipant mentre se si trovano in uno stati di \textit{Global Commit} manda il segnale di Commit.

\paragraph{2PC}
Nel metodo \texttt{closeTransaction} del coordinator viene implementato il protocollo 2PC. Il coordinator ottiene dal repository tutti i partecipant che hanno fatto join alla transazione e chiama in maniera asincrona il metodo \texttt{canCommit} su ognuno di loro. Una volta effettuate le chiamate, inizia la fase di raccolta dei voti: per ogni partecipant si attende un tempo pari a \textit{voting\_single\_timeout}. Prima di controllare per la richiesta successiva si controlla che il tempo passato dall'inizio della fase di raccolta dei voti sia minore di \textit{voting\_total\_timeout}-\textit{voting\_delta}. In caso siano violati i timeout si procede con il global abort. Se tutti i voti sono concordi sul READY si procede chiamando in maniera asincrona il \texttt{doCommit} su tutti i partecipant altrimenti si chiama il \texttt{doAbort}. Effettuate tutte le chiamate asincrone si attende l'arrivo di tutti gli ack: si attende un tempo pari a \textit{completition\_single\_timeout} e se scade il timemout si procede alla ritrasmissione ( il massimo numero di ritrasmissioni è indicato dal valore di \textit{completition\_max\_retry}.

Tutti i valori dei timeout sono letti dal \texttt{TransactionRepository} all'avvio e vengono ottenuti attraverso il metodo \texttt{getAllTimeout()}.

\section{Replicazione}
È stato deciso di replicare lo stato della coda di TaskDescriptor utilizzando una modalità attiva di replicazione. Ogni peer ha il suo Replica Manager locale che può essere interrogato come Web Service per ottenere i dati sulle repliche possedute dal peer. La logica per ottenere e pubblicare delle repliche è contenuta all'interno dell'oggetto \texttt{ReplicaFrontend} istanziato nella classe \texttt{CORE}.

All'avvio del Worker si chiede al Frontend di trovare una replica della coda (\texttt{getReplica}) e se ne trova una coda non vuota si caricheranno i TaskDescriptor nella coda sincronizzata. Ogni volta che viene modificato lo stato della coda viene chiesto al Frontend di salvare in remoto la coda (\texttt{storeReplica}).

\paragraph{Replica Manager}
Il \textbf{Replica Manager} (RM) è implementato da un Web Service mappato su l'EJB Stateless \texttt{ReplicaManager} ed utilizza il metodo di ordinamento dei messaggi illustrato in precedenza appoggiandosi al queue manager \texttt{ReplicaQueueManager} (EJB Stateful Singleton).

Per implementare il 2PC il Replica Manager deve conservare traccia dello stato della transazione attraverso le varie chiamate (operazione-canCommit-doCommit/doAbort). A tale scopo si appoggia ad un EJB Singleton \texttt{ReplicaTransactionCache} che contiene una mappa che associa ad un transaction id un oggetto di tipo \texttt{ReplicaCacheEntry}. Quest'ultimo oggetto contiene le seguenti informazioni:
\begin{itemize}
\item \texttt{action} : tipo enum che identifica se si tratta di un \texttt{get} o di una \texttt{store}
\item \texttt{component}: identificativo del componente a cui è associata la replica
\item \texttt{content}: stringa contenente la replica se si tratta di una \texttt{store} altrimenti la rappresentazione su stringa del boolean di ritorno del metodo \texttt{getReplica}
\item \texttt{tempFile}: oggetto File contenente il riferimento al file temporaneo generato nel processo di store della replica, rimane sempre null durante il \texttt{get}.
\end{itemize}
La cache è condivisa con l'EJB che implementa la coda per l'ordinamento. Quest'ultima viene riempita attraverso i metodi del web service \texttt{ReplicaManager} con degli oggetti di tipo \texttt{ReplicaRequest}. I dati contenuti nell'oggetto \texttt{ReplicaRequest} sono i seguenti:
\begin{itemize}
\item \texttt{vclock}: vector clock della richiesta e necessario all'ordinamento
\item \texttt{componentId} : identificativo del componente a cui è associata la richiesta
\item \texttt{coordWsdl} : URL del WSDL del transaction coordinator a cui fare il join
\item \texttt{replica} : replica di cui fare la \texttt{store}, in caso di \texttt{get} vale null
\item \texttt{transId}: identificativo della transazione all'interno del quale è stata effettuata la richiesta
\item \texttt{responseAddr}: indirizzo sul quale inviare la risposta della richiesta
\item \texttt{get}: vale true se si tratta di una \texttt{get}, false se si tratta di una \texttt{store}.
\item \texttt{push}: vale true se si tratta di una \texttt{store}, false se si tratta di una \texttt{get}.
\end{itemize}

Il metodo \texttt{deliver} del Queue Manager decide in base all'operazione indicata nell'oggetto ReplicaRequest se eseguire il metodo privato \texttt{storeReplica} del Queue Manager oppure il metodo privato \texttt{getReplica} del Queue Manager; raccolto il risultato dell'invocazione di questi metodi li invia tramite socket all'indirizzo indicato nell'oggetto \texttt{ReplicaRequest}.

Il metodo \texttt{getReplica} del Queue Manager effettua il join al coordinatore di transazione indicato e poi legge il file relativo alla replica ossia il file con nome \texttt{\$COMP\_ID.rpl} nella cartella \texttt{logs/replicaStore} all'interno della root del domain dell'Application Server Glassfish. Una volta letto il file il contenuto viene memorizzato all'interno della cache sotto forma di \texttt{ReplicaCacheEntry}. Il metodo \texttt{storeReplica} del Queue Manager effettua il join al coordinatore di transazione indicato e inserisce i dati sulla replica da memorizzare in un oggetto \texttt{ReplicaCacheEntry} che viene inserito nella cache. 

L'EJB \texttt{ReplicaManager} è responsabile del protocollo 2PC dal lato del partecipant. Il metodo \texttt{canCommit()}, chiamato dal coordinator per ottenere il voto del partecipant, agisce in modo diverso a seconda che si tratti di una \texttt{store} o di una \texttt{get}. Se si tratta di una \texttt{store} viene scritto il contenuto del campo \texttt{content} della \texttt{ReplicaCacheEntry} all'interno di un file temporaneo creato nella cartella \texttt{temp} all'interno della \texttt{replicaStore} (directory all'interno del quale vengono registrate le repliche); il file temporaneo viene memorizzato nella entry all'interno della cache. Se si tratta di una \texttt{get} non viene eseguita nessuna azione particolare (non ci sono dati da rendere permanenti).

Il metodo \texttt{doCommit} rende permanenti le modifiche della transazione. Nel caso di una \texttt{store} il file temporaneo contenuto nella entry della cache viene spostato nella directory \texttt{replicaStore} e rinominato con l'identificativo del componente a cui è associata la replica e gli viene assegnata l'estensione "\textit{.rpl}"; finite queste operazioni viene cancellata la entry dalla cache (le operazioni non sono più annullabili). Se si tratta di una \texttt{get} si cancella solamente la entry nella cache (non ci sono dati da rendere permanenti).

Il metodo \texttt{doAbort} cancella le entry nella cache e nel caso di \texttt{store} viene cancellato anche il file temporaneo generato dal metodo \texttt{canCommit}.

\paragraph{Ricezione dei Response}
Il \texttt{ReplicaFrontend} permette all'applicazione POJO di usufruire del sistema di replicazione mascherando la complessità del sistema distribuito. Le risposte provenienti dai Replica Manager arrivano al frontend attraverso delle socket aperte su un indirizzo passato al Web Service come parametro. Un thread implementato dalla classe \texttt{ReplicaResponseHandler} si occupa di creare la \texttt{ServerSocket} cercando una porta libera a partire da quella indicata nel file di configurazione. Questo thread rimane in ascolto in attesa delle risposte dei Replica Manager e inserisce tali risposte in una lista passatagli tramite costruttore; una volta raccolte tutte le risposte il thread termina. 

Il metodo \texttt{getReplica} inizia la transazione, avvia il thread per raccogliere le risposte e inizia ad eseguire le richieste di \texttt{getReplica} a tutti i Replica Manager conosciuti dal servizio di discovery (in questa implementazione il vicinato viene caricato dal file \texttt{discovery\_peers.xml}). Fatte tutte le richieste, il metodo fa join sul thread di ricezione delle risposte: quando tutte le risposte sono state raccolte, si chiama il metodo \texttt{closeTransaction} del coordinator e si attende la response della transazione.

Il metodo \texttt{storeReplica} è chiamato molte volte e durante l'esecuzione dell'applicazione POJO al contrario del \texttt{getReplica} che viene chiamato una volta sola in fase di caricamento dell'applicazione. Per evitare che le chiamate alla \texttt{storeReplica} peggiorino le performance dell'applicativo, il frontend lancia un thread \texttt{ReplicaStorerThread} che esegue le operazioni di store della replica senza bloccare l'esecuzione. Il thread avvia la transazione, avvia il thread per collezionare le risposte e invia le richieste di store a tutti gli RM conosciuti dal servizio di discovery. Finite le chiamate, effettua il join sul thread per collezionare le risposte e, quando riprende, effettua la \texttt{closeTransaction} attendendo l'esito della transazione.

\section{Deploy e Configurazione dell'Applicazione}
Il lavoro svolto è stato diviso in tre applicazioni Enterprise:
\begin{itemize}
\item \textit{MiddlewareGlobalLoggerApp}: contenente gli EJB per il Logger Globale
\item \textit{MiddlewareGlobalMonitorApp}: contenente gli EJB per il Monitor Globale
\item \textit{MiddlewareReplicationApp}: contenente gli EJB per i Replica Manager e i Transaction Coordinator.
\end{itemize}
L'applicazione del primo step è contenuta nel progetto \textit{ProgettoMiddleware}. Nella cartella \texttt{dist/} si trovano i file \textbf{EAR} (Enterprise Archive) per le applicazioni e
saranno inseriti, tramite l'Administration Console di Glassfish, all'interno dei domini appropriati. 
Oltre ai file EAR, vi è il file JAR dell'applicazione POJO.

I file di configurazione per l'applicazione POJO sono :
\begin{itemize}
\item \texttt{middleware\_config.xml}: contenente i dati per configurare l'applicazione.
\item \texttt{discovery\_peer.xml}: contenente i dati sui peer conosciuti dal servizio di discovery.
\item \texttt{peer\_config.xml}: contenente i dati per configurare il peer.
\end{itemize}
I file di configurazione per l'applicazione per la Replicazione sono:
\begin{itemize}
\item \texttt{coordinator\_config.xml}: contenente le configurazioni per il coordinatore delle transazioni
\item \texttt{replica\_manager\_config.xml}: contenente i dati per configurare il Replica Manager.
\end{itemize}
I file di configurazione dell'applicazione POJO devono trovarsi nel path di esecuzione mentre i file di
configurazione delle applicazioni Enterprise si devono trovare nella cartella \texttt{config/} situata
all'interno della directory \texttt{domains/domain\_name} dell'Application Server \textit{Glassfish}. 
Segue una veloce descrizione del contenuto dei file XML di configurazione.
\paragraph{middleware\_config.xml}
Il root tag \texttt{<middleware>} deve contenere i seguenti Child Node:
\begin{itemize}
\item  \texttt{<architecture>}: indica il tipo di architettura del sistema, e.g. \textit{P2P}
\item \texttt{<transport>}: indica il protocollo da utilizzare per le comunicazioni, e.g. \textit{TCP}
\item \texttt{<file\_transfer\_policy>}: indica la politica di trasferimento dei File, e.g. \textit{PUSH}
\item \texttt{<global\_logger\_wsdl>}:  contiene l'URL dove trovare il file WSDL di descrizione del servizio di Logging globale, e.g. \textit{http://localhost:8080/GlobalLoggerService/\\GlobalLogger?wsdl}
\item \texttt{<global\_monitor\_wsdl>}: contiene l'URL dove trovare il file WSDL di descrizione del servizio di Monitor globale, e.g. \textit{http://localhost:8080/GlobalMonitorService/\\GlobalMonitor?wsdl}
\item \texttt{<local\_coordinator\_wsdl>}:  contiene l'URL dove trovare il file WSDL di descrizione del servizio Coordinatore locale responsabile per le transazioni, e.g. \textit{ http://localhost:8090/\\TransactionCoordinatorService/\\TransactionCoordinator?wsdl}
\item \texttt{<replica\_response\_port>}: indica da quale porta iniziare la scansione atta a trovare una porta libera per ricevere i response dal servizio di replica, e.g. \textit{33333}
\end{itemize}
\paragraph{discovery\_peer.xml}
Il root tag \texttt{<discovery>} deve contenere un numero N di elementi \texttt{<peer>} ognuno dei quali
deve avere i seguenti Child Node:
\begin{itemize}
\item \texttt{<ip>}: indica l'IP del peer conosciuto dal Discovery, e.g. \textit{127.0.0.1}
\item \texttt{<port>}: indica la porta sul cui contattare il peer, e.g. \textit{18181}
\item \texttt{<rm\_wsdl>}: contiene l'URL dove trovare il file WSDL di descrizione del Replica Manager del peer, e.g. \textit{http://localhost:8080/ReplicaManagerService/\\ReplicaManager?wsdl}
\end{itemize}
\paragraph{peer\_config.xml}
Il root tag \texttt{<peer\_config>} deve contenere i seguenti Child Node :
\begin{itemize}
\item \texttt{<ip>} : Indirizzo IP del peer corrente, e.g. \textit{127.0.0.1}
\item \texttt{<port>}: Porta su cui contattare il peer corrente, e.g. \textit{19191}
\end{itemize}
\paragraph{coordinator\_config.xml}
Il root tag \texttt{<coordinator>} deve avere l'attributo \texttt{id} contenente un valore univoco che
identifichi il coordinator (e.g. hash dell'IP oppure random hash). Il tag \texttt{<coordinator>} deve
contenere un elemento \texttt{<timeouts>} composto da elementi \texttt{<timeout>} con un attributo \texttt{name} rappresentante il nome del timeout e come contenuto il valore del timeout. I timeout da dichiarare sono i seguenti:
\begin{itemize}
\item \textit{voting\_single}: timeout sulla singola richiesta di voto, e.g. \texttt{10000}
\item \textit{voting\_total}: durata del timeout globale della fase di voto della transazione, e.b. \texttt{30000}
\item \textit{voting\_delta}: delta associato all'inizio di una nuova richiesta di voto, e.g. \texttt{ 2000}
\item \textit{completition\_single}: timeout sulla singola richiesta di completamento, e.g. \texttt{10000}
\item \textit{completition\_max\_retry}: numero massimo di ritrasmissioni in caso di timeout nella fase di completamento, e.g. \texttt{3}
\end{itemize}
\paragraph{replica\_manager\_config.xml}
Il root tag \texttt{<replica\_manager>} deve contenere un singolo elemento, \texttt{<wsdl\_url>}, contenente l'URL del Replica Manager da configurare.
\end{document}